Telecommunications networks currently rely to a large extent upon Signalling System No.7 (SS7) as the mechanism for controlling call connections and for handling the transfer of signalling information between signalling points of the networks. Typically, one or more application and user parts at a given signalling point will make use of SS7 to communicate with peer application and user parts at some other signalling point. Examples of user parts are ISUP (ISDN User Part) and TUP (Telephony User Part) whilst examples of application parts are INAP (Intelligent Network Application Part) and MAP (Mobile Application Part). The conventional SS7 protocol stack includes Message Transfer Parts MTP1, MTP2, and MTP3 which handle the formatting of signalling messages for transport over the physical layer as well as various routing functions. Both signalling and user data is carried over Synchronous Transfer Mechanism (STM) networks using either the E.1 (Europe) or T.1 (USA) systems. In some cases a common STM network is used for both signalling and user data whilst in other cases separate STM networks are used.
There has been considerable interest of late amongst the telecommunications community in using non-standard (i.e. non-conventional within the telecommunications industry) signalling and user data transport mechanisms in telecommunications networks in place of the conventional mechanisms. The reasons for this are related both to improvements in efficiency as well as potential cost savings. Much consideration has been given for example to the use of ATM (AAL1/2/5) and Internet Protocol (IP) networks to transport signalling and user data between network nodes. ATM and IP networks have the advantage that they make efficient use of transmission resources by using packet switching and are relatively low in cost due to the widespread use of the technology (as opposed to specialised telecommunication technology).
ISUP, which deals with the setting-up and control of call connections in a telecommunications network, is closely linked to the E.1/T.1 STM transport mechanisms and does not readily lend itself to use with non-standard transport technologies such as IP and ATM. As such, several standardisation bodies including the ITU-T, ETSI, and ANSI, are currently considering the specification of a signalling protocol for the control of calls, which is independent of the underlying transport mechanism. This is illustrated in FIG. 1 and can be viewed as separating out from the signalling protocol those Bearer Control functions which relate merely to establishing the parameters (including the start and end points) of the “pipe” via which user plane data is transported between nodes, and which are specific to the transport mechanism. The new protocol, referred to as Bearer Independent Call Control (BICC) or Transport Independent Call Control (TICC), retains Call Control functions such as the services invoked for a call between given calling and called parties (e.g. call forwarding), and the overall routing of user plane data. It is noted that signalling traffic at the Call Control level may be sent over a network (IP, ATM, SS7, etc) which is separate from the network over which Bearer Control signalling traffic and user data is sent. However, in some cases a single shared network may be used. As well as TICC, alternative transport independent call control protocols exist including SIP.
The new network architecture resulting from the separation of the Call and Bearer Control levels results in an open interface appearing between a Call Control entity and a Bearer Control entity, where these entities are referred to as a Media Gateway Controller and a Media Gateway respectively. The open interface may be referred to as a Gateway Control Protocol (GCP), examples of which are the MEGACO work of the IETF (MegacoP) and the H.248 work of ITU Study Group 16 (SG16) as well as MGCP. It is envisaged that a given Media Gateway Controller may control several Media Gateways (or indeed a Media Gateway may be controlled by several Media Gateway Controllers).
In the GCP there are defined protocol elements which correspond to respective network accesses, e.g. a timeslot, and elements which correspond to respective connections (between terminations). For example, in H.248 these elements are referred to respectively as “terminations” and “Contexts”. These same terms will be used hereinafter although it will be appreciated that different terms may be used in different GCPs, e.g. MGCP uses the terms “endpoint” and “connection”. A single termination can carry several different “streams”, each stream carrying one distinct type of information, e.g. speech or data. The streams within a given Context are related by the use of a “StreamId”. A stream consists of a uni- or bi-directional flow of data.
As implied above, a Context represents a connection between two or more terminations in one MG. By default, all terminations within a Context are connected to each other so that all terminations “listen” to all of the other terminations within a Context. The topology of a Context is defined so that the relation between two terminations (which can be identified by a “wildcard” operator) is described, i.e. Ta,Tb,Relation. The relation may be oneway (bi-directional), bothways (unit-directional), or isolated. The Topology Descriptor is conventionally a property of the Context and is maintained at the level of the MGC.
There are circumstances in which appropriate authorities may wish to monitor the calls and connections made by a given telephone subscriber. For this purpose, the unidirectional relation will be assigned to the Context at the MGC level which connects the termination allocated to the monitoring authority to the termination allocated to the subscriber to be monitored. Consider the situation where TA (termination A) represents subscriber A, TB (termination B) represents subscriber B, and TC (termination C) represents subscriber C. Assume that subscriber B is to be monitored, but that the legal warrant does not extend to the monitoring of any other parties (namely subscribers A and C), and that a conference call is setup between the three subscribers as illustrated in FIG. 2.
In the call, which is a multimedia conference, both speech and data are involved. In each termination there are two streams, one for speech and one for data. Monitoring is to be performed on subscriber B, but only on speech, and only on what B says, not on what A or C says. To be able to do this, a new termination Tmo must be included in the Context. When a connection is desired only to B, a topology needs to be described, i.e. TB, Tmo, oneway, in which TB is the “from” termination and Tmo is the “to” termination. In the above Context, Stream1 carries speech and Stream2 carries data. From the perspective of TB, Stream1 listens to everything that comes in from either A or C and sends everything that B says to A and C.